Screen access for all (SAFA) design

Overview of the system

The SAFA system is divided in three main subsystems. SAFACore module which handles interaction with windows, manages configurations,  and maintains off screen model (OSM) that represents the information available on screen. and excepts input from input module, and sends output to the output module. Input module is another subsystem which is responsible for accepting input from other input devices such as keyboard, mouse, or if desired via other input module like speech recognition. Input module allows registration via well established interface. and then the third module is output module which accepts output from the main module and sends it to registerd components with it via well established interface. output components may be speech synthesiser, braille output or any other device.

input module: responsible for registering, unregistering and receiving the input from input modules such as keyboard, mouse, and speech recognition engines. during registration, it returns an interface which is used by the input device to raise events for input. Inputs are queueed and delivered to the SAFACore module one by one.

Keyboard manager: handles low level keyboard commands, and then converts it to input messages that are exceptable to the input module. It delivers the input messages as events to the input module. the conversion process is based on the keyboard setting object, which maps key commands to the desired messages. it also sends the text representing the messages to the speech module based on the settings in the configuration module. configuration module decides whether a speicific command message will be spoken or not. key strokes to text conversion will be done via key echo Object . It will also send review mode messages in which user can use keyboard like the mouse.

keyboard setting object: This is responsible to convert key commands to input messages. it does by looking up in the keyboard configuration file which is an xml file and is specific to each language and application. for the settings for which application setting files does not have an entry, default files are looked up.

key echo object: it recieves the keystroke event and then trys to determine the character associated with. it queries the current keyboard layout for the conversion. failing on conversion, it queries KeyLayoutToCharacter object. Failure occurs due to the non standard implementation whare locale id is not used in keyboard layout. this object also stores characters in a buffer if the current echo mode is per word or any other non character mode. It will also echo for non printing key strokes i.e. keys such as tab or others for the currently selected language.

KeyLayoutToCharacter object: converts key strokes to characters by looking in to XML based files for different character codes based on code page number or custom character code whare even code page model is not followed.

file manager: responsible to return a file which matches the language id, application module name, application version, and the configuration type. each language has it's own folder, in which every application has it's own folder, this folder also has extention with the version after the first dot. the folder with no extention will be the default folder for that application.
there is a default folder which is used for all the settings which do not have there entries in the application folder.

Mouse manager: handles low level mouse commands, and then sends out the input commands to the input manager in form of input events. 

Configuration manager: maintains a configuration object which has settings for various configuration options. configuration manager maintains configurations files based on the language, and application. It obtains configuration files from file manager, and returns the file after any change. application can retreiv any configuration option from the configuration manager via set of functions.

SAFACore module: This is the hart of the system. from the time of initialization it controls and maintain various components. All the components of the system are known to the SAFACore and every other component establish there communication via this module. after communication connection, it does not interfear with there working, but at the time of shutdown it can send  shutdown request which terminates the connection.
SAFACore also interacts with input and output modules. 

Off screen Module: represents off screen model of the Operating system and the application currently visible on the screen. it recieves input from the input manager and sends it to the current control handler for the wigit. OSM module also maintains current control handler and changes it when on recieving the focus changed event from windo manager object. The current control handler is maintained in the context of the current WindowHandler which changes on recieving application change event. all the open programs with top level windows are represented in the OSM by WindowHandler. these are stored as a list of WindowHandlers and the WindowHandler associated with the forground window is represented by the current WindowHandler. Parent for all of these is the WindowHandler for the desktop window. 
The SAFACore main module maintains off screen representation of the text on the screen in the text manager. Text manager object gets key stroke events in review mode. SAFACore recieves various events from window manager for managing it's internal state.
 
Window manager: window manager maintains various MSAA hooks and monitors different events. It sends focus change event and application change event along with other window events to it's clients. clients can register with it to recieve the events.

WindowHandler: Each top level window in the system is represented by WindowHandler. WindowHandler object maintains information about the application with which it is attached and the list of control handlers which are instances of control handler classes for each type of control in the system. WindowHandler also has a reference to the current control handler which represents the control that has the focus. Information about the application is the title, module name, version if any, and current input language. 

control handlers: control handlers are various off screen objects representing different commonly available screen elements such as buttons, list box, combo box, tree view etc. the control handler objects speak the various peaces of information on getting focus or on request. details for each are given below. All of these control handlers maintain reference to a help object to announce the context sensitive help in short and long format. the short help is tipically around one line, and the long help is around a paragraph. These help messages are available for each of the languages available in the system. each of the control handlers also maintain a list of event /action. each event which is generated by keyboard or other input devices trigger action. Actions are the behaviour expected from various control objects. if the control handler does not have any action associated with the event, the event will be passed on to the parent of the control object, and if there is no action with the parent also, events are forwarded to the window with the focus. There are some events which have action associated with them, but even then they will be forwarded.

Edit control object: this is responsible to interact with the current edit control. this is one of the front components that will directly interact with the edit control. is works with both the edit control i.e. single or multi line. It maintains information about the edit control object such as single line or multi line, alignment, whether the edit control is a password field, or it is read only field. It also has reference to the edit control help object.

 Button object: it maintains information about the button, such as caption, type whether it is a simple button, check box, radio button or group box. will also have reference to button help object.

list object: will work with the list box, and will maintain information about the list box current item, number of items, and index of the current item.

combo box object: will work with the combo box, and will maintain information about the combo box current item, number of items, and index of the current item. will handle editing options also for edit combo boxes. again willh have reference to the combo box help object for small and long help messages.

Treeview object: will work with the Treeview, and will maintain information about the treeview such as current level, current item, number of items at the current level, and index of the current item. again willh have reference to the treeview help object for small and long help messages.

static Object: Will work with the static controls and which are used for labels in windows. static controls are also available to provide messages in message boxes. Will maintain information about the static control text. 

rechedit control object: this is responsible to interact with the current RichEdit control. this is also the front components that will directly interact with the RichEdit control. it works with all three versions of richedit controls such as v1.0, v2.0 and v3.0. It also works with both ansi and Unicode version of richedit control. It maintains other information such as, format,  alignment, or whether it is read only. It also has reference to the RichEdit control help object.

ms word Main object: controls interface with microsoft word via Component Object Model (COM) Automation. works with different versions of word by instanctating the relevant version object. works with word 95, 97, 200, XP, and 2003. Main job of this object is to control interaction between the safa system and the handler object for the current version of word. It detects the version and then instanciates the object. Different word handler object are named as: MSWord95, MSWord97, MSWord2000, MSWordXP, and MSWord2003. MSWordMain can also serv as the base interface for rest of the word versions. should maintain information about the current selection such as: whether the current selection is normal text, table, field, other object. on changing the current selection, it should change the internal object for that type (optionally it should raise type change event). handling of the type of text is proposed by separate objects. object being: text, table, field, and any other which comes along.

Entry for each word version will be made here after studying them.

internet_server Object: interacts with internet_Server component and maintains representation of the current page in it's own buffer. there are two possibilities to design this representation, and which one is selected needs some more research. the options are:
1. page information is maintained as Document Object Model (DOM) and reformated to suit the linear reading requirements. In this reading patern each important item appears separately on a single line. so only one link will be on one line. Ability to navigate is provided by the DOM itself. User will be given information as the dom elements change or on request. Further details can be provided only after study.

2. the page is in an array of buffer lines, which maintain information about each chunk of text. buffer line object has fields such as: type, quantum, text, handler, font, color, etc. type field has values such as: link, visited link, this page link, graphic, text, heading, table begin, table end, table nesting, row, column, frame begin, frame end, list begin, list end, block begin, block end, etc. text field is used to store text that user read. handler field contains the text which will be activated. font, color, and other attributes will help users to know about various attributes.
It changes it's state with the help of various events from the internet_server component. also has help object as well.

Text manager object: It will maintain the information about the text on the screen. text manager maintains a sorted list of line object. based on the Y coordinate and ability to add, insert, and delete lines. . On addition, it will check if the any text being added is highlighted if yes then it will be spoken. It will get this information from display driver interface DDI. It will also have the ability to cut, copy, and delete various regions on the screen.


line object: line object will contain data object, which will be sorted on x coordinate and line object will have the ability to add, delete, insert, split the data object and merge data objects if the attributes are same. 

data object: Data object represents any  object that can participate in lines. currently text data object and graphic data object are the only ones.

Text data object: this has information about each text chunk which has same attributes, attributes being: Start x, start y, font name, font size, font style, character extents, forground and background color. in case two text data objects with same attributes exists, and they are adjecent, they are merge.

Graphic data object: this represents icons on the screens.

Filter object: All the objects wanting to output information first convert the information representation to unicode before forwarding it to any other part of the system. no communication in side the system and out side the component can be in non unicode form. . Filter object provides conversion if desired. the filter will except the text in ansi and will convert to the desired unicode code space. To aid the conversion, it will also need information about the font associated with the text. Filter maintains various conversion objects, can instantiate them if needed and maintains the dictionary of converters in it's caches.

output module: will provide the ability to register and unregister the output devices. it will sent output events to the registered modules and those events are in form of predefined protocol. 

speech module: accepts text in unicode XML format with the attributes. these attributes determine how the text is to be spoken. they define language detected, language id, rate increment, pitch increment, speak phonatically, spell, and personality type. if the language detected is true, then speech engine outputs the text to the desired speech synthesiser, otherwise it parses the text and determines itself the language. it breaks the text at the language change, and sends each text in sequence to the desired synthesiser. synthesisers speak in sequence, but the entire speech module continuously excepts the text. on recieving the stop command, it flushes the queue, and synthesisers stop.

Synthesiser object: it represents each indivisual synthesiser, excepts the text from the speech system and can register itself with the speech system. each synthesiser also maintains reference to a dictionary object for the language it is interested in. Dictionary object helps in mapping words for which users want different pronunciation.

dictionary object: it is a very simple object which maintain a list of words for which it has substitutes.